畫室每隔一段時間，會有一次清倉日

堆在角落的舊畫架、調配失敗的顏料、學徒試手感留下的草稿
師傅會一件一件檢查，決定哪些留、哪些丟

沒有人喜歡清倉日，「留著，至少不會出錯；丟錯了，才要負責」
但畫室的空間有限，捨不得丟的東西堆多了，真正要用的工具，反而找不到

讓人不敢刪的，通常不是技術問題

過去六天，我們認出了六種「贅肉」
但認出問題，跟真的動手刪掉，中間常常隔著一句猶豫：

「這個類別，會不會其實還有地方在用？」
「這段程式碼，是不是某個我不知道的舊功能留下的？」
「刪錯了，誰負責？」（這個最常發生）

這些猶豫，大多不是技術問題，是信心問題
不確定刪掉之後，系統還完不完整

刪之前，先把信心補齊

安全刪除一段可疑的無用程式碼，通常需要走過這幾步：

• 搜尋所有呼叫端
  • 不只是直接呼叫，也包括反射、依賴注入容器裡的註冊、設定檔裡用字串指定的類別名稱
  • 這幾種呼叫方式，IDE 的「Find Usages」不一定抓得到，得手動再確認一次
• 確認測試涵蓋這個判斷
  • 如果刪除之後，既有測試全部維持綠燈，這是一個強訊號
  • 如果沒有測試覆蓋這段邏輯，先補一個「刪除前的行為快照」測試，會比裸刪更安心
• 檢查有沒有功能旗標（feature flag）還指向它
  • 有些程式碼看似沒人呼叫，其實是因為對應的功能旗標關閉了，而不是這段邏輯真的沒用
• 獨立成一個小 PR
  • 刪除的動作，不要跟其他功能改動混在同一個 PR 裡
  • 混在一起，審查的人很難只針對「這段真的能刪嗎」把關，常常會被功能改動分散注意力

走完這四步，還是刪錯了，git 還找得回來，這是清倉日最大的安全網
真正該提防的，不是刪錯，是連確認的力氣都沒花，就決定「先留著比較保險」

「以後可能用得到」，是清倉日最常見的藉口

Day 24 的猜測性通用，常常帶著這句話：「先做成可擴充的，以後說不定用得到」

清倉日要問的是反過來的問題：這個彈性，加上去到現在，有沒有真的被用過？
如果從加上去那天到現在都沒用過，「以後」大概率也不會用到

真正要延伸彈性的時候，需求會很具體
因為那時候，你面對的是一個真實存在的第二種情境，而不是一個「說不定」

回頭對照 Day 02 的規矩表

模組四的六個警訊，跟 S / O / L / I / D 的對應，不像前三個模組那麼工整
它們的共同點，不是違反某一條特定的規矩，是讓「該不該存在」這個判斷，變得模糊

但有一個間接的關聯值得留意：一個類別的職責如果本來就切得夠乾淨（S），要判斷「這段程式碼還有沒有用」會容易得多，因為它的邊界清楚，呼叫端也清楚

職責混雜的程式碼，連「這段是不是死的」都很難確定，更別說安心刪除

清倉日清得動，通常是因為前面的地基打得夠乾淨

自我檢查清單

1. 我對「這段程式碼真的沒人用」這件事，有多少信心？信心是怎麼來的，搜尋過，還是猜測？
2. 有沒有反射、依賴注入註冊、設定檔字串，可能繞過一般的呼叫搜尋？
3. 刪除前，有沒有測試能證明「刪掉之後，行為沒有改變」？
4. 這次的刪除，是不是獨立成一個只做刪除的 PR？
5. 「以後可能用得到」這句話，這次是不是有具體的情境撐著，還是純粹的猜測？

明日預告

明天我們進入最後一個模組，文藝復興畫室的分工倫理：師傅與學徒，不該互相代筆

過度的耦合者，正式開工